REMARKS 

Reconsideration of the above-identified application, as amended, is 
respectfully requested. 

This response/amendment is in reply to the Office Action dated May 2, 2008, 
in which all pending Claims 4-11, 16-21, 26-31 and 33-37 were rejected by the Examiner 
including the new independent Claims 35-37 added in applicant's prior response of April 21, 
2008. 

Particularly, in the Office Action, Claims 26-31 and 37 were rejected under 35 
U.S.C. 1 12, first paragraph, as allegedly failing to comply with the written description 
requirement. Particularly, the Examiner alleges that there is no disclosure in the Specification 
for a program storage device readable by a machine. 

Applicants respectfully disagree. Figs. 2 and 3 describe the hardware and 
software infrastructure including a machine (CPU element 55, Fig. 2) for reading program 
code, flash and DRAM memory (element 58 in Fig. 2) that supports system code (i.e., 
program instructions) and further includes in Fig. 3, watchpad software including: an 
operating system that allows multiple user level and kernel level threads to run and will 
support multitasking and multi_user support; device drivers; a client_server graphics 
subsystem; a communication subsystem manager; a synchronization manager; middleware 
such as Tcl/Tk, Javascript, Perl, etc., may run on top of the operating system, graphics and 
communication manager APIs, and, Application software such as Personal Information 
Management (PEM) applications for calendars, phone books, to do lists, etc., will be resident 
above the basic graphics, communication and synchronization subsystems. 
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Further, Figs. 6, 7A-7B and 8 provide original disclosure of the server 
operations which comprises a programmed computing device including a machine for reading 
instructions. Moreover, the specification on pages 16-17 describe how the central server is 
"programmed". 

Thus, in response, applicant respectfully submits that the present specification 
discloses a program storage device readable by a machine and the Examiner is respectfully 
requested to withdraw the rejection of Claims 26-31 and 37 under 35 U.S.C. 112, first 
paragraph. 

Further in the Office Action, Claims 4-1 1, 33 and 35 were rejected under 35 
U.S.C. §103(a), as allegedly being unpatentable over Ran et al. (US Patent No. 6,209,026) 
(hereinafter "Ran") in view of Shibata (US Patent No. 5,835,923) (hereinafter "Shibata"). 

Further, Claims 16-21, 26-31, 34, 36 and 37 were rejected as being 
unpatentable over Ran. 

Applicants respectfully disagree. 

First of all, each of independent Claims 35, 36 and 37 are being amended in 
this important respect that Ran does not speak to nor suggest: namely the provision of the 
wireless in-building beacons as part of the second communications sub-system for said 
wireless data transmission and the additional control server functionality that is required in 
order to successfully synchronize the data transmission to the wireless wrist watch receiver 
device after placing the wireless data receiver device of the wrist watch device in a receive 
mode of operation. 

That is, each of independent Claims 35, 36 and 37 are being amended to set 
forth (e.g., in the case of Claim 36) the additional steps of: 
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determining, at said server control device, a wireless beacon closest to said wireless 
data receiver and transmitting said data to said wireless data receiver via said beacon, and, 

determining if said wireless data receiver is out of range from the beacon: and, if it is 
determined that said wireless data receiver is out of range from the beacon, said beacon 
communicating a last piece of data that was successfully transferred to the wrist watch device 
to the server control device, and. 

waiting at said server control device until another beacon notifies the server device 
that the wireless data receiver is in range, and. 

in response, said server control device continues transmitting said data to said wireless 
data receiver via said another beacon . 

Respectfully, no new data is being entered as full support can be found in the 
specification, e.g., at page 21, line 25 to page 22, line 13 which speaks to the alternate 
embodiment to paging, and Fig. 6 (in-building wireless beacon element 750). 

The additional steps added to amended Claims 35-37 are not taught nor 
suggested by Ran. That is, Ran does not teach nor suggest 

determining, at the server control device, a wireless beacon closest to the wireless data 
receiver and transmitting the data to the wireless data receiver via the beacon, and. 

deternrining if the wireless data receiver is out of range from the beacon: and, if it is 
determined that the wireless data receiver is out of range from the beacon, the beacon 
communicating a last piece of data that was successfully transferred to the wrist watch device 
to the server control device, and. 

waiting at the server control device until another beacon notifies the server device that 
the wireless data receiver is in range, and, 
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in response, the server control device continues transmitting the data to the wireless 
data receiver via the another beacon . 

By performing these new Claim steps, complete transmission of wireless data to the 
user devices is ensured even if the user happens to fall out of range with an in-beacon wireless 
transmission system. 

Respectfully, Ran does not provide such functionality for enabling a beacon to 
communicate a last piece of data that was successfully transferred to the wrist watch device to 
the server control device . In fact, as Ran is a "push" model for pushing data to a user at a 
specified frequency, the user' device may receive the next traffic "update" at the specified 
interval; and consequently, its server controller device does not have to be notified or 
remember what tbe last piece of data transmitted is, as in the present invention. That is, Ran 
is not concerned about the completeness or sufficiency of the data being demand-pulled 
unlike in the present invention. 

Absent a teaching or suggestion in Ran, applicants respectfully submit that 
Claims 35-37 as amended herein, is patentably distinct from Ran whether taken alone or in 
combination with Shibata. 

Moreover, to reiterate some of the other key distinctions: 

The implementation of a wrist watch device including a wireless data receiver 
device for receiving wireless data communications that includes implementing a user 
identification code that forms part of the data request for uniquely identifying a user's wrist 
watch device and ensuring proper data transmission thereto at a specified time and location is 
neither taught nor described in Ran. 

Notwithstanding the Examiner's rejection where the Examiner alleges that Ran 
discloses the request includes a user identification code for uniquely identifying the user's 
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"wearable appliance" and ensuring proper data transmission thereto (at col. 2, lines 30-40 of 

Ran), applicants' respectfully disagree. 

That is, contrary to the Examiner's reasoning provided in her rejection of 

Claim 2, Ran (US 6,209,026) does not state what the Examiner has alleged. Instead, this 

passage of Ran merely states the following: 

In accordance with a still further aspect of the present 
invention, said central processing system assigns a universal user ID and 
password to a registered user and said user uses one or several of the 
following individual means and procedures to receive personalized real- 
time traveler information and warning: (1) filling or revising 
infonnation/warning request forms and requesting a universal user ID 
and password for all individual means for receiving information and 
warning; (2) receiving personalized real-time traveler information; (3) 
receiving personalized abnormal real-time travel condition warning. 

Thus, Ran must be interpreted as merely disclosing: "(1) filling or revising 
mfomatior^warning request forms and requesting a universal user ID and password for ALL 
individual means for receiving information and warning; (2) receiving personalized real-time 
traveler information; (3) receiving personalized abnormal real-time travel condition 
warning, "(Emphasis Added). 

Consequently, Ran does not teach or suggest anywhere that "said request 
includes a user identification code for uniquely identifying the user's wearable appliance and 
ensuring proper data transmission thereto " as alleged. Rather, the instant invention as now 
claimed in amended Claims 35, 36 and 37 in which the data request includes a user 
identification code for uniquely identifying the user's wearable appliance and ensuring proper 
data transmission thereto. 

Rather in Ran, a universal ID is provided to identify ALL devices, with no 
unique identification provided for any specific receiver device in Ran (See Ran, at col. 2, lines 
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37-38 "requesting a universal user ID and password for ALL individual means for receiving 
information and warning"; and, Ran at col. 9, line 60-61 "wherein a universal user ED and 
password for ALL individual means for receiving information will be sent to the user") 
(Emphasis added). 

Thus, Ran requests only a universal user ID and password for receiving 
information and warning instead of a user identification code for uniquely identifying the 
user's wearable appliance as required by the instant invention. Thus, Ran's user ID is only 
implemented to provide data to a specific user, while in the present invention, the user ID is 
used further to identify a specific wrist watch device associated with the user and placed in a 
"receive" mode to receive a data communication at a specified time and location. 

The features of amended independent Claims 35-37 clarify further novel 
aspects of the present invention that are neither taught nor suggested by Ran: namely, that it 
provides users with an asynchronous demand-pull functionality for a wearable digital 
appliance (e.g., a "smart" wrist watch) that implements a wireless data receiver device by 
providing a method for communicating data to the wearable appliance so that the device may 
receive wireless data communications at a user-specified time and location and without user 
participation. User participation is not required in the present invention as the user device 
may be programmed to awake the data receiving channel from a sleep mode of operation to 
automatically receive the data transmission at the requested time and location if no other 
application on the device needs to use the receiving communication channel. This is 
facilitated by the specification of a user identification code that forms part of the data request 
for uniquely identifying the user's wrist watch device and ensuring proper data transmission 
thereto . To the contrary, in Ran, there is no need to specify the "location" of the device where 
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user requested data is to be received as it simply does not provide the asynchronous pull 
functionality using two communication sub-systems in the manner as claimed. 

Moreover, in the rejection of Claim 35, while Shibata has been cited as 
providing the teaching of a wake-up device, again, applicants submit that the device in 
Shibata awakes a whole device from a powered off or sleep mode that includes a timer that 
will turn on an AC power source (in view of Shibata Fig. 1 5 which connotes that the Shibata 
receiver device is NOT a mobile device such as a wrist watch). Shibata describes this in the 
context of a publication/information tiansmitting and viewing system that includes 
programmable timing functionality to awake a newspaper data decoder device 52 from a sleep 
state and for enabling a tuner/receiver device 51 and a newspaper on-demand terminal 53 to 
be powered up under control of a timer (Fig. 15 of Shibata). This is not what is being claimed 
in amended Claims 35-37, as Shibata has nothing to do with a wrist watch device and that fact 
that Shibata uses an ac power source, is not a mobile device for receiving data personalized 
for a user. Thus, one would not be motivated to look to the publishing arts such as described 
in Shibata to make up the deficiencies of Ran and thus, it is respectfully submitted, is not 
combinable with Ran. 

For all the foregoing reasons, applicant respectfully submits that amended 
independent Claims 35 — 37 are patentably distinct over Ran, whether taken alone or in 
combination with Shibata, and the Examiner is respectfully requested to withdraw the 
rejections of all claims under 35 U.S.C. §103(a) and to allow these claims and all Claims 
dependent thereon to proceed to issuance. 

In view of the foregoing remarks herein, it is respectfully submitted that this 
application is in condition for allowance. Accordingly, it is respectfully requested that this 
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application be allowed and a Notice of Allowance be issued. If the Examiner believes that a 
telephone conference with the Applicants' attorneys would be advantageous to the disposition 
of this case, the Examiner is requested to telephone the undersigned, Applicants' attorney, at 
the following telephone number: (516) 742-4343. 



Scully, Scott, Murphy & Presser, P.C. 
400 Garden City Plaza, Suite 300 
Garden City, New York 11530 
(516) 742-4343 
SF:gc:bk 



Respectfully submitted, 




Registration No. 34,594 
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